你可能不需要微前端

其實蠻多人都會諮詢我關於微前端的開發，他們對微前端有種美好的誤會，認為可以用微前端解決當前的效能問題、共用問題、溝通問題。其實不然，微前端只是會帶來更多問題，跟微服務概念不同，它帶來的是完全不一樣的方向。當前的前端發展建立的是龐大的應用程式，當後端按照 Domain knowhow 分出了數十個微服務時，前端依然是一坨巨大的單體式架構，而微前端是在此誕生去解決管理問題的。

你該使用微前端嗎？

你可以不斷詢問自己，我們該使用微前端嗎？如果你從來沒使用過這種架構，我絲毫不推薦你使用，它帶來的複雜度可以說是超級高。但你會疑惑，怎麼會有一種只帶來煩惱的架構？它確實會帶來很多困擾，也要盡可能讓自己思維抽離原本前端開發所習慣的思考，不然會在各種限制上感受到非常陣痛。

舉例來說，你可能會覺得使用 react-router 這類型的 Library 不是什麼大問題，大家都在用。但微前端溝通上卻是個問題，你會破壞副作用的資料流，帶來更多狀態同步問題。

再舉例，你可能覺得使用 react-query 這類型的 Library 不是什麼大問題，大家都在用。但微前端上一些實作行為和快取是無法相互溝通的，你沒有建立起一道溝通橋樑，應用間的快取是不被溝通的，你只是在浪費記憶體。

什麼時候該使用微前端？

正如我最前面所說的，會有一些情境比較合適開始導入微前端來處理。

當一個 Web Side 需要有一塊技術線落差非常大的功能掛載進來

這種情況是你可能原本架構都用 React，但突然有天你需要開發一個以 Canvas 或是 Vue 為基礎技術的功能，當一個專案同時管理兩個技術差異甚大的公能，多少會面臨嚴重的水土不服和混亂。

當你需要兩個以上的團隊開發同一個 Web Side 時

也有種情況是公司前端已經是多團隊協作，這會發生在公司有多個產品線時。很可能前端不再是協作開發單一產品，每個產品或複雜功能採用最適合的技術線大不相同，此時整合上會充滿困難。更麻煩是你很難去統合過大團隊的技術線，每個人都會有意見，每個人都有自己的技術偏好。此時拆成微前端進行管理會相對輕鬆很多，發揮微前端對於管理上的強大優勢。

有共同 Context 時，有強制力可以去耦合

大部分在單體式架構上，程式原始碼的耦合會十分強，就像前面講的「我就是 import 來 import 去」。當有一個 Context 作為解耦的溝通橋樑，使用一個 Framework 的概念，可以把高階邏輯轉的依賴移到抽象去。既然複雜架構下都可以被抽離了，既然高階邏輯可以被抽離，低階 Framework 作為 package 發布並共用，這也與微前端的運作邏輯進而相仿，你可以按照需要直接做切分。但實現這架構的難度異常高，並不是隨便一個團隊可以輕易選擇的。

我真的需要微前端，那我還需要評估什麼？

當你評估你真的需要微前端，最終你會有相當的試錯成本，網路上資源匱乏，沒有足夠豐富的資訊可以參考。大部分都是很粗暴、簡單的分享，很少足具實作深度的分享。但學習是需要在實戰中累積，如果沒有豐富的底層知識和架構經驗，是很難駕馭這個架構。實作過的經驗建議，不要太相信自己任何實作策略，要積極建立各種抽象層，以防某種架構要被放棄時可以作為退路，保持彈性去更版迭代架構。